The multimedia communication service is a primarily developed service in the Next Generation Network (NGN), and is implemented by using the IP-based packet switched technology to transmit multimedia packets over a wired or wireless channel.
The multimedia communication service generally selects an IP (Internet Protocol) network as a bearer network for the transmission of the multimedia data. However, as a bearer network, the IP network has the disadvantage that it cannot provide a full QoS (Quality of Service) guarantee. Although some strategies have been developed to provide certain QoS for the bearer layer of the IP network, it is far from being sufficient to provide services for a carrier class network. Thus, for a multimedia communication service which utilizes the IP network as its bearer network, especially a communication service with a high real-time demand, such as the audio/video communication, a corresponding measures for QoS guarantee from the bearer layer to the application layer of the network should be established so as to ensure the accurate transmission of the multimedia data. The measures for QoS guarantee should take into account not only the problems such as multi-path and fading associated with the wireless channel, but also the problems of the multimedia packets during transmission cause by network congestion such as delay, and packet loss.
When the data packets obtained by packetizing the multimedia data are transmitted over the IP network, they may be lost due to the transmission quality of the transmission channel. Accordingly, the packet loss will lead to a decreased recovery quality of speeches or images received by the receiving end, and thereby a significant deterioration of the overall performance of the multimedia communication. So in a multimedia communication system, the resilience and correction of errors due to the packet loss is very critical for improving the quality of the multimedia communication. The common correction measures include the packet retransmission mechanism and Forward Error Correction (FEC) mechanism.
The packet retransmission mechanism means to require a transmitting end to retransmit the lost packet(s). In this way, the problem of communication quality degradation due to the packet loss can be solved effectively. However, the communication delay due to the lost packet retransmission by the transmitting end is usually intolerable for a session-based application, such as a video-conference, etc., especially for an application based on IP multicast service which is now increasing rapidly. In such a case, it is impossible to provide packet retransmission for each user to retransmit the lost packet(s). For this reason, the retransmission mechanism is generally applicable to only the multimedia communication services which have a relatively low real-time demand.
The FEC mechanism is usually applicable to the multimedia communication services with a higher real-time demand. For the multimedia communication data transmitted based on IP network, the FEC mechanism for it often utilizes the Erasure Codes to recover the lost packets effectively. The principle of the Erasure Codes is as follows:
The receiving end recovers the lost packet(s) according to the inherent redundancy between the received packets. At present, a Reed-Solomon (RS) Code is generally used as the common Erasure Code. In the case of a code rate of ½, a RS Code enables the recovery of 33% of the lost packets. However, the computational complexity is much higher when utilizing a RS Code to recover the lost packets, which limits the application of the RS Code to the services with a large amount of data.
The H.264 standard, in which many error-resilience approaches are presented, is an IP-oriented video compression codec transmission standard finally constituted in May, 2003 by the International Telecommunication Union (ITU). The RFC 2733 protocol which supports the H.264 standard and is advanced by the Internet Engineering Task Force (IETF), i.e. “An RTP Payload Format for Generic Forward Error Correction” protocol, specifies a payload format of the multimedia data encapsulated in a Real-time Transport Protocol (RTP) data packet. The RFC 2733 protocol specifies three RTP packetization approaches for the FEC mechanism. Based on these three RTP packetization approaches, the FEC algorithm is to perform an Exclusive Or (XOR) operation to RTP data packets to generate FEC check packets, wherein the format of the generated FEC check packets also follows the format of the RTP data packets; then the transmitting end transmits the RTP data packets and the generated FEC check packets to the receiving end respectively; the receiving end recovers the lost packet(s) due to the quality of the transmission channel according to the received RTP data packets and the FEC check packets.
The three RTP packetization approaches for the FEC mechanism specified in the RFC 2733 protocol are as follows:
(1) The First Scheme:
a   b   c   d   e_each letter represents onemultimedia data packet followingthe RTP format;f(a, b)  f(b, c)  f(c, d)  f(d, e)_each function value representsone FEC check packet;
The meaning of the above representation is: for a sequence of multimedia data packets a, b, c, d, e . . . , a XOR function expression f( ) is used to generate the corresponding check packets. For example, if the data packets a and b are input parameters respectively, the output value f(a, b) derived from the XOR operation of the function f( ) is regarded as a check packet, i.e.:
f(a, b) = a ⊕ b_the check packet f(a, b) is obtained by performing XORoperation on each binary bit of the data packet a and eachcorresponding binary bit of the data packet b in a properorder;
In this way, the rest may be deduced by analogy, that is, the check packets f(b, c), f(c,d), f(d, e) may be obtained respectively;
(2) The Second Scheme:
f(a, b)  f(a, c)  f(a, b, c)  f(c, d)  f(c, e)  f(c, d, e)_each functionvaluerepresents oneFEC checkpacket;
The process for generating each of the check packets is the same as that of the first scheme;
(3) The Thirst Scheme:
a   b   c   d_each variable represents onemultimedia data packetfollowing the RTP format;f(a, b, c)  f(a, c, d)  f(a, b, d)_each value represents one FEC checkpacket;
The process of generating each of the check packets is also the same as that of the first scheme.
In summary, the relationship between the RTP data packets and the FEC check packets may be described using a mathematical model of a check matrix: in which the elements of the check matrix are 0 or 1. If the element at the crossing of the mth row and the nth column is 1, it means that the mth check packet and the nth data packet are correlated (i.e. the related packets, as the parameters of the function f( ) respectively, participate in the generation of the check packet). While if the element at the crossing of the mth row and the nth column is 0, it means that the mth check packet is independent of the nth data packet.
For example, the relationship between the RTP data packets and the generated FEC check packets in the third scheme can be expressed by the following check matrix:
      [                            1                          1                          1                          0                                      1                          0                          1                          1                                      1                          1                          0                          1                      ]                      a                    b                    c                    d            
In the above matrix, a, b, c and d represent four data packets respectively; the first check packet f1=f(a, b, c)=a⊕b⊕c because each of the elements at the crossings of the first row with the columns in which the data packets a, b and c are located is 1. Similarly, the second check packet f2=(a, c, d)=a⊕c⊕d and the third check packet f3=f(a, b, d)=a⊕b⊕d. Each of the check packets is generated by performing an XOR operation on each corresponding bit of each of the data packets.
Also in the RFC2733 protocol, the length of the longest RTP data packet is used as a reference, zero(s) are padded at the end of the rest data packets so that the lengths of all of the data packets participating in the XOR operation may be made identical. Therefore, the length of a FEC check packet is equal to that of the longest data packet participating in generating the FEC packet.
The three RTP packetization approaches for the FEC mechanism advanced in the RFC 2733 protocol have the following characteristics respectively:
The first scheme enables the recovery of a single lost data packet with a probability of 100%, and the recovery of any two lost data packets with a probability of 94%; however it cannot recover three successively lost data packets. The redundancy of this packetization approach is 44.4%, in which:Redundancy=the number of check packets/(the number of data packets+the number of check packets)×100%.
The characteristic of the second scheme lies in that only the check packets are transmitted while the data packets are not transmitted, and the original data packets are recovered according to the received check packets at the receiving end. The redundancy of this packetization approach is 16.7%. However, this scheme can recover only any single lost data packet as well as certain successively lost data packets, but cannot recover the data packets according to a single received check packet.
On a condition that the redundancy is 42.9%, the third scheme can recover any single lost data packets, two successively lost data packets or certain three lost data packets. The probability of completely recovering three lost data packets is 80%, however this scheme cannot recover three successively lost data packets with a probability of 100%.
For example, when the packets f(a, b, c), c and f(a, c, d) are lost at the same time, the packet c cannot be recovered; when the packets f(a, c, d), f(a, b, d) and d are lost simultaneously, the packet d cannot be recovered.
In addition, during the process of calculating and generating the check packets, the length of the longest data packet is used as the reference, zeros have to be padded at the ends of all the rest data packets such that the lengths of all the data packets participating in the XOR operations are identical, and thus the length of a generated check packet is equal to that of the longest data packet participating in generating the check packet, which by all means leads to a higher bit overhead occupied by the check packets and hence a lower data transmission efficiency.
As can be seen from the above that the packetization approaches in the RFC 2733 protocol have an insufficiency in the capability of recovering the lost data packets so that the lost packet(s) due to the quality of the transmission channel cannot be recovered efficiently, which brings about a deterioration in the overall performance of the multimedia communication to a certain extent.